System and method for the automatic generation of printable files from data 



5 Description: 

The invention relates to a system for the automatic generation of printable files from 
data in a database, said system comprising a printing system consisting of at least one 
print processing component, whereby the print processing component has means for 
10 printing and/or further processing the files. 

The invention also relates to a method for the automatic generation of printable files 
from data in a database, according to which method the files are generated, printed out 
and/or further processed by a printing system consisting of at least one print 
1 5 processing component and one print job generation element. 

The generation of printable files is acquiring increasing significance since ever- 
greater volumes of print objects are being generated electronically, further processed 
and printed out in a wide array of application areas. In particular, there is a need to 
20 generate individualized mailpieces by electronic means and to subsequently print out 
and further process them. 

For example, postal service providers offer nvimerous services in the letter and 
mailing realm that go well beyond the mere sending of letters and parcels. Such a 
25 system supports the entire production process for documents that are printed and that 
are to be sent out. With the growing significance of electronic mail, this also holds 
true in the realm of e-mail communication and Intemet-based logistics. 

hi this context, components of a system designed for such procedures serve various 
30 purposes. On the one hand, they serve as a receiving interface and production system 
for letter mailings that are ultimately printed on paper and that are delivered to the 
recipients by mail. On the other hand, system components with interfaces offer a 
direct transfer capability for messages via electronic means. Thus, the sending and 
delivery can be carried out through e-mail and web protocols. 
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A number of production-related obstacles have to be overcome in order for users to 
make use of these options. This ranges from the design of a mailing and the acquisi- 
tion of target group addresses to the actual serial printing, including quality control. 
5 Even when specialized service providers such as letter shops and printing centers are 
used, the creation of mailings still proves to be quite a complex process. Multiple 
media discontinuities and heterogeneous interfaces or approaches among all kinds of 
intermediates involved make the process expensive and complicated for small mail 
volumes. For large-scale mailings, it is time-consuming and technically complicated. 

10 

In order to print and further process print jobs within a printing system, various print 
processing components such as printers, sorting and enveloping machines or other 
processing devices are typically used. This leads to multi-faceted possibilities in terms : 
of hardware combinations and job sequences, each requiring a special print 
15 preparation. 

Print preparation methods for all kinds of requirements are known from the state of 
the art - DE 199 21 120 C2, for example, describes a method and a system for the 
signature-wise imposition of printing data within a POD (Print On Demand) system. . 
20 This involves the printing and folding of printed sheets, a process in which the printed 
images of consecutive pages are positioned so as to match precisely. 

Furthermore, DE ICQ 17 785 C2 describes a method and a system for processing a 
data stream in which the data stream is prepared to be output by a printing device. 
25 Here, a print data stream that is present in a first print data format is converted into a 
standardized data format and the print data stream thus converted is indexed on the 
basis of prescribed indexing criteria. The indexed print data stream is then sorted in a 
sorting sequence according to sorting parameters and the sorted print data stream is 
output for purposes of further processing, especially for being printed out. 

30 

In actual practice, the problem often arises that print jobs are transmitted to different 
printing systems, whereby each printing system requires a different print preparation. 
This is particularly the case when, for example, a postal service provider receives data 
for print jobs from users of a service system designed for this purpose, stores this data 
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in a central database and transmits the command for the execution of the print jobs to 
its own system components or to printing service providers. Typically, each printing 
service provider has its own specific printing system with different software and 
hardware components. In order for the user jobs to be prepared uniformly and to be 
5 transmitted to the particular printing system of the service provider once the data has 
been received by the postal service provider, the postal service provider has to know 
all of the specifications of the commissioned printing service provider. This, in turn, 
calls for extensive hardware and software on the part of the postal service provider. 

10 DE 198 17 878 Al, for example, discloses a method and a device for producing, 
, wrapping and enveloping printed mailings. Here, the party ordering a print job 
produces the print data and transmits it via a network to a printing means, where the 
transmitted print data is printed out. The ordering party produces the print job on his 
personal computer, which is connected to one or more central computers. The central 

15 computers are connected to servers that can be located, for example, in different cities 
or countries. The ordering party selects a server with free printing capacity and 
transmits the print job to this server. This print job is executed fully automatically on 
the selected server, whereby the server preferably has another personal computer and 
a printing means. The print job is stored on the personal computer and it controls the 

20 printing means and its various components such as paper rolls and gluing machines as 
well as printing, cutting, wrapping and folding imits. 

Moreover, DE 101 23 488 Al describes a printing system for printing a plurality of 
jobs in one system having a plurality of processing stations. Each of the processing 
25 stations is used to render the documents into a ready-to-print file format and to issue 
an electronic job ticket containing global document properties. In this case, a 
customer transmits an order for objects to be printed either directly in paper form, on 
a data carrier or else via the Internet. 

30 DE 101 22 880 Al discloses a method for the automatic generation of printing 

instructions. For this purpose, a user enters instructions at a computer in response to 
which the computer places a plurality of received docimients into an electronic folder 
and arranges the documents in the folder in the desired order for the printed final 
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product. Here, a customer's job for objects to be printed is likewise transmitted to the 
printing system either directly in paper form, on a data carrier or else via the Internet. 

The invention is based on the objective of creating a system that allows a printing 
5 system to receive data from a database outside of the area of the printing system and 
to automatically generate printable files on the basis of this data as a function of the 
specific requirements of the printing system. 

It is likewise an objective of the invention to provide a method for the automatic . 
10 generation of print jobs from data in a database by a printing system in which the 
database is located outside of the area of the printing system. 

According to the invention, this objective is achieved by a system for the automatic 
generation of printable files from data in a database, said system comprising a printing 
1 5 system including at least one print processing component, whereby the print 

processing component has means for printing and/or further processing the files, said 
system comprising the following features: 

• the printing system has at least one print job generation element, 

20 

• the print job generation element can be connected to a server via a first 
interface, 

• the server can be connected to a database via a second interface, 

25 

• the print job generation element has means for requesting and receiving 
data from the database, and 

• the print job generation element has means for preparing the data from the 
30 database as a function of the requirements of the print processing com- 
ponent and it also has means for generating printable files. 

The objective is also achieved by a method for the automatic generation of printable 
files from data in a database, by means of which the files are generated, printed out 
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and/or further processed by a printing system consisting of at least one print 
processing component and one print job generation element, and the method includes 
the following steps: 

5 • the print job generation element generates a first message that contains a 

call to a server for a specific method with parameters, 

• the print j ob generation element establishes a connection to the server via 
a first interface, 

10 

• the print job generation element transmits the first message to the server 
via the first interface, 

• the server processes the first message in that it calls the specific method 
15 with the appertaining parameters, 

• the server establishes a connection to the database via a second interface, 

• the server retrieves data from the database via the second interface, 

20 

• the server sends the result of the call for the specific method in the form of 
a second message back to the print job generation element and 

• the print job generation element generates at least one printable file fi-om 
25 the result of the call for the specific method. 

The printing system is, for example, a system at a service provider comprising print- 
ers, sorting and enveloping machines and/or other processing devices. According to 
the invention, a print job generation element that can be connected to a server is 
30 installed in such a printing system. The server, in turn, can be connected to a database 
containing data for print jobs to be generated. The database is located outside of the 
printing system and typically comprises large volumes of data. This data comes, for 
example, fi^om users of a service system of a postal service provider who have placed 
orders for print jobs for mailings. 
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The print job generation element according to the invention is typically a program that 
is preferably installed on computers of the printing system. The term "computer" here 
is not to be understood in any limiting manner. This can be any unit that is suitable for 
5 executing computations such as, for example, a work station, a personal computer, a 
microcomputer or circuitry that is suitable for executing computations and/or 
comparisons. 

In an especially preferred embodiment of the invention, the print job generation 
10 element in the form of a first interface can be connected to a SOAP server via a SOAP 
interface. The abbreviation SOAP stands for Simple Object Access Protocol. SOAP is 
a conmiunication protocol for access to individual program modules on the Intemet. 
SOAP is a lightweight protocol with which proprietary modules can be packaged and 
provided with generally understandable interfaces. SOAP specifies how a function 
1 5 procedure call takes place with XML data via computer platforms (Remote Procedure 
Call). Advantageously, a connection to the server is possible via the Intemet, but other 
connections are also possible. These can be temporary or permanent connections. 

According to the invention, the server can be connected to at least one database via a 
20 second interface. In an especially preferred embodiment of the invention, a PL/SQL 
layer is used for the connection between the server and the database. The abbreviation 
PL/SQL stands for Procediu"al Language/Structured Query Language. This is a 
proprietary programming language, for example, for Oracle, that adds procedural 
constructs and control possibilities to the non-procedural SQL. Via the server, data 
25 from the database is transmitted to the print job generation element, said data 

containing, for example, templates, variable data, personalization instructions and 
other information about the print jobs that are to be produced. 

The print job generation element produces print jobs from the received data and 
30 automatically generates printable files. In this process, the print job generation 
element describes how the files are to be prepared for a certain paper/hardware 
combination. This includes, for example, information pages for the personnel, control 
characters for an enveloping machine, crop marks, paper formats, the production of 
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RIP tickets for printers, SDL control characters, conversion instructions and 
instructions on how the data is transported to a printer. 

The data in a database constitutes jobs from users pertaining to the printing of mail- 
5 pieces. Jobs from users are referred to below as UserJobs, whereas the resultant print 
jobs are designated as PrintTobs. Since the UserJobs produced by users can be of 
greatly varying sizes, and since advantageously, the Print Jobs should be neither too 
large nor too small for purposes of optimal production, it has proven to be practical to 
divide large jobs and/or to combine several small jobs into larger ones. For this 
10 purpose, special preference is given to the implementation of a mechanism that 
automatically divides large jobs. 

Additional advantages, special features and practical refinements of the invention can 
• be gleaned from the subordinate claims and from . the presentation below of preferred 
15 embodiments making reference to the figures. 

The figures show the following: 

Figure 1 the schematic structure of a system for the automatic generation of 
20 printable files; 

Figure 2 a representation of the method of a call to a SOAP server; 

Figure 3 a representation of the method of a call to a SOAP server via SOAP; 



25 



30 



Figure 4 a detailed representation of a call to a SOAP server via an Apache SOAP 
API; 

Figure 5 the representation of a server proxy class. 

Figure 1 schematically shows the structure of the system for the automatic generation 
of printable files with reference to an especially preferred embodiment. According to 
the invention, a printing system 10 has a print job generation element 15. The printing 
system is located, for example, at a printing service provider that is part of a mailing 



system, whereby this mailing system accepts, prepares and further processes 
electronic data from users into letters, postcards and/or e-mails. The data from users 
and appertaining jobs is advantageously stored in a database 30 that is located outside 
of the area of the printing system. 

5 

Printing service providers typically have different printing systems with specific 
requirements for different print processing components 14, whereby the print process- 
ing components can comprise, for example, printers 11, sorting machines 12 and/or 
and enveloping machines 13. Consequently, according to the invention, a print job 
10 generation element 15 is used for the specific preparation of data in the area of the 
printing system 10. The print job generation element 15 is typically a program that is 
preferably installed on one or more computers of the printing system 10. 

In order to allow the print job generation element 1 5 and thus the printing system 10 
15 to access the contents of a database 30 outside of the area of the printing system, and 
in order to automate these steps, in an especially preferred embodiment of the 
invention, a client-server architecture was selected that uses SOAP as the 
communication mediimi via the Internet. For this purpose, the print job generation 
element 15 is connected via a first SOAP interface 40 to a SOAP server 20 outside of 
20 the area of the printing system. This first interface is preferably realized via the 

Intemet 60. However, other types of connections can also be selected and these can be 
temporary or permanent connections. 

A SOAP interface has the advantage over proprietary communication protocols such 
25 as CORBA (common object request broker architecture) or RMI (remote method 

invocation) that, for example, during the data transmission, no conflicts occur with a 
firewall of the print job generation element 15 and/or of the printing system 10. SOAP 
preferably uses HTTP/HTTPS as the data transmission protocol. HTTP/HTTPS is 
either permitted through most firewalls or else it is tunneled via proxies, so that it is 
30 not necessary to adapt the firewalls and no new points of attack are created. Moreover,, 
by using a SOAP protocol that uses the HTTP protocol as the basic transport protocol, 
a simple transmission via the Intemet is possible. 
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All of the methods that the print job generation element 15 needs in order to receive 
all of the necessary information from the database 30 for a print job are provided via 
the SOAP interface 40. Advantageously, the system is secured against outside access. 
The system can be secured in different ways. For example, an authentication of the 
5 print job generation element 15 at the server 20 can be employed. Moreover, it is 
advantageous to use HTTPS (HTTP Secure) as the transmission protocol. 

In an especially preferred embodiment of the invention, access of the SOAP server 20 
to the database 30 is carried out via a PL/SQL layer 40. In this manner, it is possible, 
10 among other things, to protocol all database accesses or to set certain attributes. This 
has the advantage that consistency of the database can be ensxu'ed. 

It has proven to be advantageous to execute all status changes in the print job genera- 
tion element without establishing a connection to the Internet and to then send the 
15 executed changes to the server. This has the advantage that the print job generation 
element only has to have a temporary connection to the Internet, and can operate even 
without a permanent Intemet connection. An Intemet connection only needs to be 
established for the merging operations with the server. 

Furthermore, an advantage of the system according to the invention is that updates for 
the configuration of the print job generation element can be stored centrally on the 
server. In an especially preferred embodiment of the invention, the print job 
generation element checks at the start whether any updates are available and it 
updates its configuration automatically from the central server via JavaWebStart. 

It is also especially advantageous to execute the actual communication via SOAP 
through an Apache SOAP API. The abbreviation API stands for Application Program- 
ming Interface, and it is an interface specified by an operating system or an 
application program by means of which standardized software tools are made 
available to other applications. Hence, an API allows an application program to use a 
function and/or services of another software. In contrast to a file interface, an API is a 
so-called call interface. The advantages of using an API lie, for example, in the 
reduction of programming work and in a imiform user interface and mode of 
operation. 
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Figure 2 shows an embodiment of a method sequence in which the print job genera- 
tion element 15 calls a method on the server 20 and, after successftiUy executing the 
method, receives a result as the return value. 

5 

Method calls via SOAP appear as XML messages that are sent via HTTP. Figure 3 
shows the schematic sequence of such a call. The print job generation element 15 
generates a first SOAP message 1 6 indicating which method with which parameters is 
to be called. This SOAP message is then transmitted via the Internet 60 to the SOAP 
10 . server 20 by means of the HTTP protocol. This server 20 evaluates the information 
and data and then sends back a result as the second SOAP message 17. 

: In detail, the SOAP call appears using the Apache SOAP API as shown by way of 
\ example in Figure 4. The print job generation element generates an instance of the 
15 call class of the Apache SOAP API and at first sets certain properties for this object. 
Figure 3 shows various methods by way of example that are called by the print job 
generation element 15. 

A TargetObJect-URI method corresponds, for example, to an unambiguous URI that 
20 is associated on the server side in the RPC router with a certain object (in the case of 
. the example here, with the SOAP server). 

A mapTypes method is preferably called several times so as to be able to transmit its 
own classes (for example, UserJob, User) via the SOAP. 

25 

The method name can be specified via a setMethodName method, and a list of 
parameter values can be set via setParams. 

An invoke method carries out the actual call via SOAP. A first message 16 is gener- 
30 ated and this is then sent to the server 20 via HTTP. 

It has proven to be advantageous that, on the part of the server 20, first of all, a web 
server 21 accepts the query and evaluates it. The web server can be, for example. 
Tomcat. In order to allow a successful SOAP call, a sent URL has to be associated 
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with the Apache SOAP API's RPC router-servlet where the server-SOAP object is 
known. The call is transmitted to this servlet. The abbreviation URL stands for 
Uniform Resource Locator. Via a URL, all documents in the Internet can be 
unambiguously addressed. 

5 

The RPC router-servlet then analyzes the SOAP inessage, determines the class to be 
called and instantiates it. Then the desired method with the transmitted parameters is 
called. The possible return value is then, in turn, converted into a second SOAP 
message 17 and this is retumed as a response via HTTP. The call object 18 on the 
10 client side analyzes this message and returns the obtained result to the print job 

generation element 15. In case of an error, a failure object can optionally be queried 
here. 

If a print job generation element 15 calls a method on the SOAP server, then, in an 
15 especially preferred embodiment of the invention, it can use a ServerProxy class. A 
proxy server accepts requests from a client and retums them — optionally modified - 
to the original destination. 

Such a sequence is shown in Figure 5. The ServerProxy 22 encapsulates the Apache 
20 SOAP API, and offers all of the methods of the server to the print job generation 
element. A call for such a method is then forwarded via the Apache API and the 
retum value is once again retumed. 

The SOAP response message is analyzed and 

25 

• in case of an error, an exception is launched or 

• in case of success, the result is retumed. 

The appropriate methods then convert primitive data types, which are retumed as 
30 objects, into the appertaining primitive data type and then retum said date types. Thus, 
for the particular print job generation element, the SOAP communication is not 
transparent but rather the ServerProxy 22 behaves as if it were calling local methods 
(except for the longer runtimes of the methods). 
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In an especially preferred embodiment of the invention, the RPC (Remote Procedure 
Call) is selected for the communication. RPC provides a remote procedure call. 
Within the scope of this concept, each server in a network makes a nimiber of services 
available that can be called with RPC. These functions are implemented as procedures 
5 of a program and can be addressed by indicating the server address, program number 
and procedure number. RPC offers the possibility of transmitting method calls and 
their parameters in a simple manner. This does not specify the transmission of entire 
XML trees as a parameter or return value. In the case of the SOAP server, preferably 
an expansion of the SOAP API of Apache is used, which specifies how XML trees 
10 can be transmitted via the SOAP RPC. Thus, UserJobs can be transmitted as method 
parameters via the Apache SOAP API. 

The SOAP RPC protocol also offers the possibility to transmit simple data types such 
as strings or integers. However, complex data types can also be transmitted in structs 
15. or arrays which, in turn, consist of simple data types. 

Various complex data types (for example, LogicalProduct, User, UserJob) are typi- 
cally transmitted during the communication between the print job generation element 
15 and the server 20. In order to be able to transmit these data types in the SOAP RPC 

20 protocol, methods are advantageously implemented that convert the classes as SOAP 
stmcts and vice versa (serialization / deserialization). However, this step is simplified 
by the Apache SOAP API in that it provides a class that offers this functionality for 
all classes that comply with a JavaBeans specification. This is why the three data 
classes are advantageously implemented on the basis of the JavaBeans specification 

25 and can thus be transmitted via the SOAP API in a simple manner. JavaBeans are a 
portable platform-independent component model that is written in Java. 

Below, an especially preferred embodiment of a print job generation element that is 
installed in a printing system is presented by way of an example. Especially advanta- 
30 geously, the realization of the print job generation element is in the form of an XML 
configuration. Such a configuration can control the entire production sequence for the 
printing. The operation advantageously takes place via a graphic user interface by 
means of which, for example, actions can be initiated and parameters can be entered. 
The printable files can be transmitted automatically to a production printer. 
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By means of the print job generation element, a printing system can transfer orders 
assigned to it, for example, from a mailing system to its own local systems and it can 
report back to the mailing system about the processing status. As a local application, 
5 the print job generation element assumes the central function of preparing the print 
. data. The preparation of the print data can comprise, for example, the following 
functions: 

• preparation of job data in XML format to create throughput-optimized 
10 printing machine jobs and finishing-specifie print jobs. 

• combining individual print jobs. 

• converting print jobs into other formats if a printing machine needs this 
15 format. 

• Providing print jobs with machine-specific control characters needed for 
automatic processing. These can be, for instance, barcodes. 

20 • Generating reprints in order to allow post-processing of individual mail- 

ings in case of production errors. 

The configuration of the print job generation element advantageously consists of 
modules, virtual printers and settings. 

25 

General settings such as, for example, paths and communication parameters, are 
configured in the settings. The parameters can be changed by means of a user inter- 
face of the print job generation element. The following table lists the mean- 
ing/function of a few possible setting parameters by way of example: 

30 

Parameter Fimction 

http.proxy '*true" or "false" determines whether the Intemet connec- 

tion is made via a proxy. 

http.proxy.host Proxy host name 
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http.proxy.port 
http.proxy.loginbox 



http.proxy.user 

http.proxy.passwd 

soap.protocol 

soap. host 
soap .port 
soap.path 
soap.serviceid 
http.auth 
http.auth.user 
http . auth.passwd 
site 

instanceid 

basepath 

outputpath 

temppath 

queuemanagerpath 

errorpath 

partnerid 

partnemame 

partnerstreet 

partnerpc 

partnertown 

wamingdays 

compatibility 
archivesample 

pdflibserial 



Port to be used for the communication with the proxy 

"true" or "false" determines whether the user interface 
displays a loginbox at the time of the login at the partner 
server in which user name and password for the proxy 
can be indicated. 

User name for proxy login 

Password for proxy login 

The protocol to be used for the SOAP communication. 
For example, "http" and "https" are supported 

Host name of the SOAP partner server 

The port to be used for the SOAP communication. 

The path on the SOAP partner server 

The service ID on the SOAP partner server 

"true" or "false", determines whether 

User name for HTTP authentication 

Password name for HTTP authentication 

Name of the production site 

Instance ID of the instance used. Serves for the use of 
several computers at one site 

Basepath 

Output path for the generated files 

Path in which temporary files are stored 

Path in which a queue manager stores its files 

Path in whiph the error log files are stored 

Partner ID of the printing service provider 

Name of the printing service provider 

Street of the printing service provider 

Postal code of the printing service provider 

City of the printing service provider 

Number of days after a UserJob whose status has not 
changed is to become, for example, yellow in the user 
interface 

Must equal "false" 

Number of addresses above which specimen copies are to 
be produced for a UserJob 

Serial number for the PDF lib 



In order to generate printable files from a PrintJob XML file, it has proven to be 
advantageous to provide a PDF kemel. The way in which the printable files are 
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produced is described by a configuration language. The kernel is informed by the 
interface of only one PrintJob XML file and one virtual printer to be used, 

In order to generate print data, the print job component receives job data consisting, 
5 for example, of a template in PDF format and variable data for the personalization and 
meta-information in XML format. Making use of an external PDF library, which can 
be located, for instance, in the database 30, the print job generation element finally 
generates completed PDF files. The generation technique depends on the job data and 
on the hardware-independent meta-information such as, for example, the size of the 
10 print job, sorting according to postal criteria, routing slip instructions for the postal 
delivery and/or attachments. It is also carried out as a function of hardware-specific 
meta-information such as imposition, performance optimization and/or specific 
barcodes that are configured in the virtual printers. 

1 5 The generation technique also depends on how the processing is defined. Therefore, 
the print job generation element is also an interpreter that derives its logic from a 
processing file, preferably in XML format. For instance, if a print job generation 
element is supposed to be able to generate folding greeting cards with text on one side 
rather than generating postcards, then merely the processing file has to be adapted. 

20 This is carried out at a central place in the mailing system and, at the time of the next 
start-up, the change is automatically transmitted to the print job generation element so 
that the print job generation element can now generate greeting cards with text on one 
side. 

25 The possibilities for producing a document are very multi-faceted and depend on 

several factors such as the original format, desired colors, paper format to be printed, 
final processing and printers employed. In order to describe how a document is to be 
produced for a concrete case, the term * Virtual printer" has been introduced. A virtual 
printer describes the prerequisites under which a document can be produced with said 

30 printer and how the document will be prepared for this concrete case. 

It is possible that different documents can be produced with the same virtual printer, 
for example, color as well as black-and-white docimients could be generated with a 
color printer following the same preparation. It is possible for different virtual printers 
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to use the same physical printer for the printing, for example, documents having the 
original format of DIN A4 can be printed on DIN A4 as well as on DIN A3 with a 
subsequent post-production. The two cases call for different preparation of the files 
and thus have to be prepared with different virtual printers. However, both virtual 
5 printers can send the files to the same physical printer if the latter is capable of 
printing DIN A3 as well as DIN A4. 

The virtual printers are generated in the configuration and processed step-by-step by 
the PDF kernel during a PrintJob production. 

10 

At the start of the production, the kernel is informed about the virtual printer to be 
used. Then the PrintJob XML file is read in, fi-om which the internal data stmctures 
that are needed for the fiirther production are built up. 

IS During the entire production, the production kernel ascertains which side of the letter 
is on the produced pages of the PDF docmnents. A CreateTemplatePDF fimction can 
be used to generate the static part for the production. For this purpose, empty pages 
have to be personalized. When these personalized pages are imposed, the kemel 
ascertains where the individual letters will be positioned. The personalized PDF file 

20 can be changed at will. This includes, for example, adding pages, changing the page 
sequence, adding texts and lines and performing the imposition. Only imposed files 
may not be imposed once again. Once the personalized PDF file (variable part) has 
been completely processed, CreateTemplatePDF can be used to generate a matching 
static PDF file. Here, a PDF file is generated on the basis of the PDF templates of all 

25 of the UserJobs and all of the necessary combinations appear once in this PDF file. 

For the later generation of a job ticket for a production printer, a data stmctxire is built 
up that describes which variable page fits with which static page. 

Attributes of CreateTemplatePDF are, for example, the following: 

30 

Attribute 
PageWidth 
PageHeight 



Function 

Page width of the PDF template to be generated 
Page height of the PDF template to be generated 
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VariableFileName Personalized PDF file for which a static template is to be 
generated 

A Condition function can be used as an attribute for some functions so that these are 
executed under certain conditions. The following instructions evaluate the Condition 
"AddText", "AddLine" and ^TsfewPDF". The condition under which the instruction 
should be executed can be specified by indicating a keyword. 

The following keywords, for example, can be implemented: 



Keyword 
doArchive 

intemal^customer 
external^customer 
ContainsCurrentlnfoPostCriteria 



Function 

Is o nly executed i f specimen c opies are 
to be printed 

Is only executed if the user of the User- 
Job is an intemal user. Always yields 
false. 

Is only executed if the user of the User- 
Job is , an external user. Always yields 
true. 

Is executed if there are letters for the 
InfoPost criterion set 



ContainsCurrentlnfoPostCriterialnLoop Is executed if a set InfoPost criterion is 

present within a loop 



StartOflnfoLetter 

SingleUserJob 

MultipleUserJobs 

EndOflnfoLetter 

StartOflnfoPost 



Is executed if the start of the InfoLetter 
letters is within the loop 

Is executed i f o nly o ne User Job i s c on- 
tained in this PrintJob 

Is executed if several UserJobs are con- 
tained in this PrintJob 

Is executed if the end of the InfoLetter 
letters is within the loop 

Is executed if the start of the InfoPost 
letters is within the loop 
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EndOflnfoPost Is executed if the end of the InfoPost 

letters is within the loop 

StartOflStandard Is executed if the start of the Standard 

letters is within the loop 

EndOfStandard Is executed if the end of the Standard 

letters is within the loop 

ContainslnfoLetter Is executed if the PrintJob contains 

InfoLetter letters 

ContainslnfoPost Is executed if the PrintJob contains 

InfoPost letters 

ContainsStandard Is executed if the PrintJob contains 

Standard letters 



Within a SendToPrinter function, a rip ticket can be created, the PDF files can be 
converted and the completed files can be sent to a printer. ' 

5 A CreateRipTicket fiinction configures how a rip ticket is to be created. As an attrib- 
ute, the file name has to be set with the destination name. Within CreateRipTicket, 
several Line descriptions are created in combination with DataLines, The Data 
attribute is set within Line, All of the texts of Line are written consecutively into the 
rip ticket file. In doing so, given variables are replaced. Repeat loops and loops can be 
10 built in at any desired place. 

With a UserJob having the ID 10000105, in which eight variable PDF pages are 
formed, for example, the following rip ticket file is generated: 

1 5 ; Book Ticket File created by Mailingfactory - SIMPLEX 

BOOK book_l 00001 05 

"M_l 00001 05"( 1 ) @"V_1 00001 05_0'X1) 
20 "M_10000105"(l) @"V_10000105_0'X2) 

"M_l 00001 05"( 1 ) @"V_1 00001 05_0"(3) 
"M_l 00001 05"( 1 ) @"V_1 00001 05_0"(4) 
"M_10000105"(1)@"V_10000105_0"(5) 

"M_l 00001 05"(2) @"V_1 00001 05_0"(6) 
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"M_l 00001 05"( 1 ) @"V_1 00001 05__0"(7) 
"M_l 0000 1 05"(3) @"V_1 00001 05_0"(8) 

ENDBOOK 

PRINTRUN pr_l 00001 05 

book_l 00001 05, bcopies=l 
ENDPRINTRUN 



10 With a Convert function, the PDF files can be converted, for example, into a format 
such as PostScript. Possible attributes of Convert are: 

Attribute Function 

Method The conversion method 

ProgramToUse Name of the conversion program 

Printer The printer that is to be used for the conversion into 

PostScript 

DeletelnputFiles Optional, true or false. Determines whether the input files are 
to be deleted after the conversion. 

With a NewPS tag, the print job generation element is instructed to convert a PDF file, 
15 for example, into PostScript. Tags are separator characters for command information 
in HTML. An attribute of NewPS in Convert can be InputFileName: 

Attribute Function 

InputFileName The name of the file that is to be converted 

With a SendFile function, files can be sent directly to a printer. Possible attributes of 
20 SendFile are the following: 

Attribute Function 

Command The command with which the file can be sent to the printer 

FileName The name of the file that is to be sent to the printer 

Delete If this attribute is present, the file is automatically deleted 

after begin sent. 



Any number of virtual printers can be set up in the configuration of the print job 
generation element. With a virtual printer, it is possible to configure which jobs can 
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be processed with this virtual printer and how the documents are to be generated. A 
virtual printer has, for example, the following set up: 



<VirtualPrinter Name="DP 4635 SIMPLEX" AddressesPerPly="20a 

5 Description="A DIN A4-PDF with addresses and template in one"> 
<PrintJobConditions> 



1 0 </PrintJobConditions> 
<PrepareJobDocuments > 



1 5 </Prepare JobDocuments> 
<SendToPrinter> 



20 </SendToPrinter> 



The attributes of VirtualPrinter can be, for example, the following: 
Attribute • Function 

Name Name of the virtual printer. This is advantageously displayed 

in the user interface and should provide information about 
the function 

AddressesPerPly Number of addresses that are processed per step during the 
hidden assignment of the PrintTobs. 

Description Can be used to store a more precise description for later 

legibility 

25 With Print JobConditions, it is possible to regulate which jobs can be produced with 
this virtual printer. Here, name- value pairs can be indicated, whereby the name must 
match a UserJobAttribute. The value in Value indicates which value the attribute must 
have so that the UserJob can be produced with this virtual printer. As soon as a 
condition does not apply, the UserJob cannot be produced with this virtual printer. 

30 UserJob attributes that are not indicated under the PrintJobConditions can be as 
desired. 
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Within PrepareJobDocuments, any number of PrepareDocumentSteps can be set up. 
These steps are carried out consecutively in order to produce the documents. 

V^ithin PrepareDocumentStepy it is described how a PDF document is generated. This 
S document can also be used in further steps as the template. Loop, Repeat and 

NewPDF can be used within PrepareDocumentStep. It is also possible to indicate a 
module whose content is executed as follows: 

<PrepareDocumentStep Name="Create InfoPostCriteria StartPage" 
10 I Module=''StartPage InfoPostCriteria simplex'V> 

Modules can also be created on the level of settings and VirtualPrinter. These mod- 
ules can be referenced by several PrepareDocumentStep entries in various virtual 
printers. 

15 

Within a Loop, all of the commands contained therein are repeated. The number of 
repetitions is a function of the setting of AddressesPerPly in the virtual printer and of 
the nimiber of addresses in the PrintJob (NumberOfPieces). The loop is repeated as 
often as AddressesPerPly fits into NumberOfPieces. If there is a remainder, this is 
20 advantageously rounded off. 

Loop is used, for example, to execute "hidden JobSplitting". During a loop pass, a 
variable LoopNo is set in each step. This variable can be used to generate various 
document names. 
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Repeat can be used to execute instructions multiple times. The number of repetitions 
can be parameterized. During the pass, the variable RepeatNo is set. The attributes of 
Repeat are, for example, the following: 

Attribute Fimction 

Start The starting value of RepeatNo 

Count The number of passes to be executed 

Action Optionally, this can be used to set environmental variables 

during each pass, as a function of RepeatNo. The following 
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are supported, for example: 

"SetCompany"-> can be used if a PrintJob stems from sev- 
eral UserJobs of different companies in order to iterate for 
the companies 

"SetInfoPostCriteria"-> can be used in order to iterate for the 
various InfoPost criteria 

"SetCompanyUserJob"-> can be used in order to iterate for 
the UserJobs of the Company 

A new PDF document can be generated with NewPDF. Within NewPDF, instructions 
have to be given as to how the PDF docimient is to be generated. The following 
instructions, for example, are possible within NewPDF: "Repeat", "WorkFlow", 
5 "PersonalizeOnTemplate", "Personalize", "CreateTemplatePDF" and "OpenPDF". 

NewPDF can have the following attributes: 



Attribute Fimction 

Filename Name ofthe PDF file to be generated 

- Persistence Indicates whether the file to be generated is to exist only 

temporarily or whether it should be retained after the produc- 
tion has been ended. 

Values: 

"Temp" -> the file is deleted after the production 
"Final" -> the file is retained 

Condition Optional, 

10 It has proven to be especially advantageous to use WorkFlows which describe how a 
docimient is to be generated. Within WorkFlowSy for example, VariableData^ Merge 
and Impositioning can be allowed. WorkFlow advantageously has no attributes. If 
several WorkFlows are created consecutively, then they are processed, for example, 
consecutively, whereby the result of a WorkFlow always serves as the source of the 

15 next WorkFlow. 



A PersonalizeOnTemplate command causes a new PDF file to be created in which 
several letters are consecutively located that consist of the PDF template and that are 
personalized with the data records from the variable data. The number of letters 
20 depends on the AddressesPerPly attribute. In order to generate letters for all ofthe 
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variable data, PersonalizeOnTemplate has to appear within Loop. As a resuh, several 
PDF files are formed, each with a number of AddressesPerPly letters. If the number 
of addresses is not precisely divisible by the AddressesPerPly^ then the remaining 
letters are located in the last PDF file. If there are different UserJobs in the PrintJob, 
5 then the PDF template that matches the appertaining address is used automatically. 

In order to classify mailpieces, InfoPost criteria are normally specified that can 
comprise, for example, InfoLetter, InfoPost or Standard. If such an InfoPost criterion 
is set during the personalization, then only addresses that have the corresponding 
10 InfoPost criterion are processed. 

An example of this is shown below: 



<PrepareDocumentStep Name="Personalize on Template*'> 
15 <Loop> 

<Repeat Count="3" Action="SetInfoPostCriteria" Start="r'> 
<NewPDP 

Filename="$ {TEMPPATH} \new_$ { JobID}_$ {LoopNo}_Pers_$ {RepeatNo} " 
Persistence="Temp"> 
20 <:PersonalizeOnTemplate StartPage=^"l" PageWidth="2 1 0" 

PageHeight="297"/> 
<yNewPDF> 
</Repeat> 
</Loop> 

25 I </PrepareDocumentStep> 

By means of the instructions above, several PDF files are formed in Temppath with 
the new_ID_xJPers_y name and having the following meaning: 



30 X: index for recognizing the partial packet. Runs fi'om 0 to 

"InitialNumberOfPieces"/ "AddressesPerPl/' (rounded off). 
Y: The appertaining InfoPost criterion. 1: InfoLetter; 2: InfoPost; 3: Standard. 
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The s\xm of all letters fi-om the various InfoPost criteria at a value of X equals 
AddressesPerPly or rather the remainder of the division. 
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It is also advantageous to have a Personalize function that functions Hke Personalize- 
OnTemplatey except that the personalization is not carried out on the PDF template 
but rather on a new empty document. Attributes of "personalize" can be the following, 
for example: 

Attribute Function 

Page Width Page width of the PDF file to be newly generated 

PageHeight Page height of the PDF file to be newly generated 

An OpenPDF function causes a PDF file to be opened. In the case of further instruc- 
tions, this file serves as a source. An attribute of OpenPDF is, for example. Filename: 

Attribute Fimction 

FileName The complete file name with the path to the file to be opened 

It is also advantageous that, with VariableData^ additional data can be applied to a 
PDF document. Here, the current document which was either opened by OpenPDF^ 
stemmed from the preceding WorkFlow^ or else was most recently created during the 
momentary WorkFlow then serves as the template. For this purpose, a page range has 
to be indicated. On this page range, the commands stored within VariableData are 
executed. "AddText", "AddSDL", AddLine" and "AddOMR" are possible within 
VariableData. 

Attributes of VariableData are, for example: 



Attribute Function 

Name Can be used for designation 

StartPage Start pages of the page range which is to be worked on 

EndPage End page of the page range which is to be worked on 

Step The step increment for the page range. If, for example, only 

every other page is to be processed, then Step=2 



Functions such as StartPage and EndPage can also be used for mathematical instruc- 
tions. For example, the following symbols can be supported: 
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Symbol Function 

( ) Bracketing 

* Multiplication 

/ Division 

+ Addition 

Subtraction 

% Modulo 

first Keyword for the first page ->1 

last Ke3Word for the last page of the document 



Here, £'«rfPage="last/2+r', for example, causes the pages to be processed up to the 
middle of the even-numbered pages. 

Within VariableData, an AddText function can be used in order to add a text: 



Attribute 

Data 

Rotation 

Color 

FontSize 
xPos 

yPos 

Font 



ReplaceData 



Function 

Text string that is to be inserted 

Text orientation. Possible values are, for example, 0, 90, 180, 
270 

Color in which the text is to be depicted. Possible values: 
black, blue, red, green, cyan, magenta^ yellow, white 

The font size in points 

Text starting point in the horizontal direction, measured firom 
the left-hand edge. Unit: mm 

Text s tarting p oint in t he v ertical d irection, m easured from 
the bottom edge. Unit: mm 

The font in which the text is to be depicted, for example: 
TimesRoman Helvetica CourierSymbol 
TimesBold HelveticaBold CourierBold 
Timesltalic HelveticaOblique CourierOblique 
TimesBoldltalicHelveticaBoldOblique 
CourierBoldOblique 

ZapfDingbats 

*TRUE" or "FALSE". Determines if the text is to be parsed, 
so that variables are recognized and are replaced by their 

values. 



Condition 



Optional, 
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CharSpacing Optional, indicates how many blank characters are to be 

inserted between all of the characters within the text string 

MaxLength Optional, limits the text string to the indicated number of 

characters. 



A function AddLine can be used within VariableData in order to add a line between 
two points: 



Attribute 
xStart 

yStart 

xEnd 

yEnd 

Thickness 
Color 

Condition 



Function 

Starting point of the line in the horizontal direction, 
measured from the left-hand edge. Unit: mm 

Starting point of the line in the vertical direction, measured 
from the bottom edge. Unit: mm 

End point of the line in the horizontal direction, measured 
from the left-hand edge. Unit: mm 

End p oint o f t he 1 ine t he v ertical d irection, m easured f rom 
the bottom edge. Unit: mm 

Thickness of the line in mm 

Color in which the line is to be depicted. Possible values: 
black, blue, red, green, cyan, magenta, yellow, white 

Optional 



An AddOMR function can be used within VariableData in order to add OMR control 
characters on pages: 



Attribute 
xPos 

yPos 
Sequence 



Function 

Starting point (top/left) of the control characters in the 
horizontal direction, measured from the left-hand edge. Unit: 
mm 

Starting point (top/left) of the control characters in the verti- 
cal direction, measured from the bottom edge. Unit: mm 

Determines the mode of counting of the sheet sequence (SS) 
lines. The following are supported: 0-7, 1-7, 7-1 and 7-0. If, 
for example, 0-7 is used, then the sheet sequence lines 
consecutively assume the following values: 

SSlrOl 010101 
SS2: 0 0 1 1 0 0 1 1 
SS4: 0 0 0 0 1 1 1 1 



LineWidth 



Line width of the control characters in mm 



Width 
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Line length of the control characters in mm 



Here, a "line" tag has to be added for each control character line within AddOMR. 



Attribute 

Name 

Position 



Function 



Fimction 

Can be used to describe the line function 

The position within the lines. The first position is at the place 
determined by xPos and yPos. Subsequent positions are each 
1/6 inch further in the direction of the lower edge. The 
positions have to be counted continuously. 

Describes the function of the lines. The following functions 
can be supported: 

ON: 
OFF: 
SSI: 
SS2: 
SS4: 
EVEN: 
ODD: 
LAST: 
NOTLAST 
page 



DGR: 
DZ: 



the line appears on all of the pages 
the line appears on none of the pages 
for counting the sheet sequence 
for counting the sheet sequence 
for counting the sheet sequence 
forms an even parity 
forms an odd parity 
is set on the last page of the letter 

is set on all of the pages except for the last 

of the letter 
DGR function 
DZ function 



An EmptyPagelnsert function inserts, for example, one or more new empty pages. 
Possible attributes are: 



Attribute 
PageWidth 
PageHeight 
PageNo 

Position 

NumberOfPages 



Function 

Width of the new page 
Height of the new page 

Page number of the momentary document where the empty 
page/pages is/are to be inserted. 

"After" or "Before". Indicates whether the page/pages is/are 
to be inserted before or after the PageNo 

Numbers of the empty pages that are to be inserted 



Various PDF files can be merged by means of a Merge function: 

10 
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Attribute 

Name 

StartPage 

EndPage 

Step 

Position 

Overlay 
Description 



Function 

Can be used to name a merge 

Indicates the place where another document is to be inserted 
into the momentary document. 

This attribute is important when pages are taken from the 
momentary document and from other documents alternately. 

0, if the new document is to be inserted completely into the 
indicated place, otherwise this step increment causes a page 
to be taken alternately from the current document and from 
the inserted document. 

"After" or "Before". Indicates whether the documents are to 
be inserted before or after the page designated by StartPage 

"true" or "false" 

Can be used to precisely describe a merge procedure 



Within Merge, the documents that are to be inserted are advantageously indicated 
with InsertPDF. Attributes oilnsertPDF can be, for example, the following: 



Attribute 
NewStartPage 
NewEndPage 
NewStep 

FileName 
DeleteAfterlnsert 



Function 

Start page of the range of this docimaent that is to be inserted 

End page of the range of this document that is to be inserted 

Can be used to insert every x*^ page. For example, New- 
Step="2" -> every other page from the range is inserted. 

Name of the file that is to be inserted • 

"TRUE" or" FALSE", d etermines w hether t he file i s t o b e 
deleted after being inserted 
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An Impositioning fimction is advantageous in order to determine how a document is 
to be imposed. Within Impositioning, any desired number of pages can be described. 
The page description specifies which pages from the original document are positioned 
on the new pages. The page description is preferably passed several times, whereby in 
each case, the original page to be taken is calculated once again. The number of 
passes depends on the values in Signature, Increment and on the number of original 
pages. It is preferably passed as often as the number of pages fits into 
Signature*//icre/ne/i/ (rounded off). 



1 5 Possible attributes for Impositioning are the following: 
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Attribute 

PageWidth 

PageHeight 

Increment 

Signature 



Function 

Page width for the new document 
Page height for the new docimient 
Step Increment for the page counter 

Determines the number of passes. If a single use is to be pro- 
duced. Signature has to be the number of original pages on a 
new page. 



In this context, attributes for AddPage are: 



Attribute 
StartPage 
CountDirection 

xPos 

yPos 

Rotation 

xScale 

yScale 



Function 

The original page that is positioned during the first pass 

"positive" or "negative", determines whether the value indi- 
cated for Increment is added or subtracted during each of the 
passes. 

Determines where in the horizontal direction the original 
page is positioned on the new page. Distance measured in 
mm from the left-hand edge. 

Determines where in the vertical direction the original page 
is positioned on the new page. Distance measured in mm 
from the bottom edge. 

"0", "90", "180" or "270". Determines the orientation of the 
original page on the new page. 

Serves for the horizontal scaling. At "1", the original size is 
retained, at "2", the size is doubled. 

Serves for the vertical scaling. At "1", the original size is 
retained, at "2", the size is doubled. 



Different variables can be accessed within the configuration of the print job genera- 
tion element. These variables can be used to generate a document name and different 
texts in new documents. The variables are set at the beginning of or during the 
production, depending on their function. 



For purposes of local data management, it is advantageous to have a QueueManager 
in the printing system 10 according to the invention with an installed print job 
generation element 15. It manages the necessary information such as, for instance, 
status, files and/or attributes, for all UserJobs and PrintTobs. For this purpose, the 



30 



QueueManager preferably uses a hierarchical data structure. Every time there is a 
change, this data structure is stored by the QueueManager on a storage medium such 
as a hard disk so that all of the information is still available after a new start of the 
system. The path can be configured, for example, via a QueueManagerPath attribute 
5 in a configuration file (PSSConfiguration.xml). In the path, the QueueManager 
creates a path for each of the UserJobs and PrintJobs in which the corresponding 
XML files are stored. 

An example of a QueueManager is shown below. The outermost container is always 
10 called QueueManager. In it, there are two containers: PrintJobs for all PrintJobs and 
UserJobs for all UserJobs. 
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QueueManager= { 
Print Jobs={ 
100001 79_1={ 

PageCountSum=100; 
Status= Waiting; 

LogicalProduct=MF_MAILING_PDF; 
CreationDate=05/28/2002; 

CurrentPrinter=4C - IClOO simplex/enveloping Duisburg; 
UserJobs={ 

UserJobl=10000179; 
}// End of UserJobs 
AvailablePrinter= { 

4C - IClOO simplex/enveloping Duisburg={ 
PRINT_MODE=SIMPLEX; 
PAGE_FORMAT=DIN A4; 
PRINT_COLOR=4C; 
CONTROL_DATA_ALLOWED=TRUE; 
ORIENTATION=PORTRAIT; 
} // End of 4C - IClOO simplex/enveloping Duisburg 
Merged in one PDF SIMPLEX={ 
PRINT_MODE=SIMPLEX; 
PAGE_FORMAT=DIN A4; 
CONTROL_DATA_ALLOWED=TRUE; 
ORIENTATION=PORTRAIT; 
} // End of Merged in one PDF SIMPLEX 
} // End of AvailablePrinter 
Plys={ 
Plyl={ 

Status=Waiting; 
} //End of Ply 1 
}//EndofPlys 

} // End of 100001 79_1 
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} //End of Print Jobs 
User Jobs={ 
100001 79={ 

CurrentPrinter=4C - IClOO simplex/enveloping Duisburg; 

CreationDate=05/27/2002; 

Id=l 00001 79; 

LastChangeDate=05/28/2002; 
LogicalProduct=MF_MAILING_PDF; 
PageCountSuni=l 00; 
Downloaded=TRUE; 
PageCountLetter=l ; 
Status=Waiting; 
AddressCount= 1 00; 
Percentage=10; 

DownloadedDate=05/28/2002; 
JobAttributes={ 

PARTNER_DOWNLOAD_TIMESTAMP=05/27/2002 16:28:46; 

PRINT_COLOR=4C; 

PRINT_MODE=SIMPLEX; 

POSTAGE_INFOLETTER_STANDARDLETTER=100; 
CURRENT_PARTNER_ID=5000000; 
POSTAGE_INFOPOST_STANDARDLETTER=0; 
PROJECT_ID=5160036; 

PARTNER_COMPLETION_PERCENTAGE=10; 
POSTAGE_START_DATE=05/27/2002 14: 02:406; 
PARTNER_LAST_UPDATE=05/27/2002 16:28:46; 
RANGE_OF_PAGES=l -3; 
CURRENT_PARTNER_INSTANCE=OLS; 
POSTAGE_INFOLETTER_ADD_STANDARDLETTER=0; 
TOTAL_NUMBER_OF_PAGES=100; 
NUMBER_OF_PAGES=l ; 
INITIAL_NUMBER^OF_PIECES=l 00; 
GROSS_WEIGHT=9. 16656; • 
ORIENTATION=PORTRAIT; 

POSTAGE_STA1SIDARD_STANDARDLETTER=0; 
POSTAGE_INFOPOST_ADD_STANDARDLETTER=0; 
PAGE_FORMAT=DIN A4; 
} // End of JobAttributes 
Print Jobs={ 

PrintJobl=10000179_l; 
} //End of Print Jobs 
AvailablePrinter= { 

4C - IClOO simplex/enveloping Duisbiirg={ 
PRINT_MODE=SIMPLEX; 
PAGE_FORMAT=DIN A4; 
PRINT_COLOR=4C; 
CONTROL_DATA_ALLOWED=TRUE; 
ORIENTATION=PORTRAIT; 
} // End of 4C - IClOO simplex/enveloping Duisburg 
Merged in one PDF SIMPLEX={ 
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PRINT_MODE=SIMPLEX; 
PAGE_FORMAT=DIN A4; 
CONTROL_^DATA_ALLOWED=TRUE; 
ORIENTATION=PORTRAIT; 
} // End of Merged in one PDF SIMPLEX 
} // End of AvailablePrinter 
}//End of 10000179 
} // End of User Jobs 
} // End of QueueManager 
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An example of a data structure that the QueueManager creates for a UserJob can be 
seen in the following table: 

UserJobID 

CurrentPrinter= 

CreationDate= 

Id= 

LastChangeDate= 

LogicalProduct= 

PageCountSum= 

Downloaded= 

PageCountLetter= 

Status= 

AddressCount= 

Percentage= 

DownloadedDate= 



JobAttributes 
JobAttributel== 



PrintJobs 
PrintJobl= 



AvailablePrinter 
Printer 1 
Attributel= . 



(all 

attributes) 



UserJob . (all PrintJobs) . 

PrintJobN= AttributeN= 



PrinterN 
Attributel= 

AttributeN= 



JobAttributeN= 



15 Diuing the synchronization with the SOAP server, the attributes are queried by new 
UserJobs. With these attributes, the QueueManager creates a new UserJob. In this 
process, the following approach, for example, is taken: 
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• generation of the new UserJob container 

• ID attribute is set with UserJobID 
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• status attribute is set at READY _FOR_pOWNLO AD 

• Percentage attribute is set at 0 

• LogicalProduct is set at the appropriate value 

• Downloaded is set at FALSE 

• LastChangeDate is set at the current time of day 

• the UserAttribute container is added 

• an empty PrintJobs container is added 

• AddressCount is set on the basis of the UserJob information 

• CreationDate is set on the basis of the job information 

• PageCountLetter is set on the basis of the job information 

• PageCountSum is set on the basis of the job information 

• the AvailablePrinter container is added. 

Possible virtual printers result from the configuration in a PSSConfiguration. All 
printers are inserted whose PrinUobConditions do not exclude attributes of the 
UserJob. The PrintJobConditions are stored for each printer in the structure. If, in the 
further course, one of more PrintJobs are generated on the basis of the UserJob, then 
the appropriate UserJoblDs are entered in the PrintJobs container. For each change, 
for example, in case of status changes, the LastChangeDate attribute is reset by the 
QueueManager. If the UserJob is downloaded, then DowloadedDate is set and the 
downloaded XML file is stored in the UserJob path. 

An example of a data structure that the QueueManager creates for a PrintJob can be 
seen in the following table: 



PrintJobID 

PageCountSum= 
Status= 

LogicalProduct= 

CreationDate= 

CurrentPrinter= 

StartAddress= 

EndAddress= 

UserJobs AvailablePrinter Plys 
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PrinterN Plyl ... PlyN 

Attribute 1= Status= ... Status= 

AttributeN= 

If a PrintJob is created from one or more UserJobs, then the QueueManager creates 
the appropriate PrintJob container. In this process, the following approach, for 
example, is taken: 

5 

• one or more PrintJob XML files are generated on the basis of the UserJob 
XML files 

• the PrintJob container is created 

• is set at WAITING 

10 • LogicalProduct is set, whereby the value is specified by the UserJob(s) 

• the UserJob container is created and all UserJobs from which this PrintJob is 
formed are entered 

• the AvailablePrinter container is copied and inserted by the UserJob 

• If several PrintTobs are to be generated on the basis of one UserJob, then 
IS . StartAddress and EndAddress are set (the address range for this PrintJob) 

• PageCountSum is set (number of all printed pages in the PrintJob) 

• CurrentPrinter is set at the selected printer 

• the niraiber of plys over which the PrintJob is to be divided is ascertained 
(results from the letters to be printed and from the AddressesPerPly attributes 

20 of the printer in the configuration) 

• The plys container is generated accordingly and all of the plys are set at 
WAITING 

• CreationDate is set at the momentary time of day. 

25 For each subsequent change in the PrintJob status, the LastChangeDate and the 
corresponding Percentage are updated. 

When a PrintJob is generated, a new PrintJob XML file is created on the basis of the 
UserJob XL files. This fimction is carried out, for example, by a RecreateXML class. 



UserJob 1= Printer 1= 

. (UserJob in this Attribute 1= 
PrintJob) 

UserJobN= AttributeN= 
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The UserJob XML file contains, for example, UserJob attributes, company data, item 
data and UserJob files. In an especially preferred embodiment of the invention, the 
UserJob files are Base64-encoded. Base64 is an encoding that is used by the 
MIMENCODE program in MIME standard to convert binary data into an ASCIT 
5 subset. 

The RecreateXML class comprises all of the User Jobs into one JOBTRANSFER- 
ENVELOPE. The UserJob attributes, company data and item data are taken over 
unchanged by each UserJob. The files with the print instructions and the variable data 
10 are changed by RecreateXML. The remaining files are taken over. 

If a UserJob is divided into several PrintJobs, the variable data is divided into records. 
Each PrintTob receives one of these records. 



15 The print instructions of the UserJobs can have the following format, for example: 
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<?xml version="1.0" encoding="ISO-8859-l" ?> 

<USERJOB_HANDLING_INSTRUCTIONS Version="2.1"> 
<DATA_FIELD_DESCRIPTION> 

<DATA_FIELD NAME="Company_l" ABBREV="d00"/> 
<DATA_FIELD NAME="Adr_Salutation" ABBREV="d01"/> 
<DATA_FIELD NAME="Salutation" ABBREV="d02"/> 
<DATA_FIELD NAME="FirstName" ABBREV="d03'7> 
<DATA_FIELD NAME="LastName" ABBREV="d04"> 
<DATA_FIELD NAME="Street" ABBREV="d05"/> 
<DATA_FIELD NAME="PostalCode" ABBREV="d06"/> 
<DATA_FIELD NAME="City" ABBREV="d07"/> 
</DATA_FIELD_DESCRIPTION> 
<FORMATTER_INSTRUCTIONS Version="l .0"> 
<CONTENT_ASSIGNMENT 
CONTENT_ID="CompanyLinel " 
DATA_FIELD_NAME="Company_l "/> 

<CONTENT_ASSIGNMENT CONTENT_ID="Title" 
DATA_FIELD_NAME="Adr_Salutation"/> 

<CONTENT_ASSIGNMENTCONTENT_ID="FirstName" 
DATA_FIELD_NAME="FirstName"/> 

<CONTENT_ASSIGNMENTCONTENT_ID="LastName" 
DATA_FIELD_NAME="LastName"/> 

<CONTENT_ASSIGNMENTCONTENT_ID="StreetWithNo' 
DATA_FIELD_NAME="Street"/> 

<CONTENT_ASSIGNMENT CONTENT_ID='TostalCode" 
DATA FIELD NAME="POSTALCODE" 



36 



10: 



15 



20 



25 



30 



35 



40 



45 



50 



/> 

<CONTENT_ASSIGNMENT CONTENT_ID="City" 
DATA_FIELD_NAME="City"/i> 

<EMPTYLINEBEFORECITYOBLIGATORY="FALSE"/> 
<SALUTATIONLINE LINESUFFIX="," PATTERN_ID="6'7> 
</FORMATTER_INSTRUCTIONS> 
. <PRINTING_INSTRUCTIONS> 
<PRINTFIELD_MAPPING> 

<PRINTFIELD NAME="LINE1" SPACETRIMMING="FALSE"> 
<FORMATTER_FIELD SEQ="1" NAME="LetterHead_Row_l"/> 
</PRINTFIELD> 

<PRINTFIELD NAME="LINE2" SPACETRIMMING="FALSE"> 
<FORMATTER_FIELD SEQ="1" NAME="LetterHead_Row_2"/> 
</PRINTFIELD> 

<PR]NTFIELD NAME="LINE3" SPACETRIMMING="FALSE"> 
<FORMATTER_FIELD SEQ="1" NAME="LetterHead_Row_3"/> 
</PRINTFIELD> 

<PRINTFIELD NAME="LINE4" SPACETRIMMING="FALSE"> 
<FORMATTER_FIELD SEQ="1" NAME="LetterHead_Row_4"/> 
</PRINTFIELD> 

<PRINTFIELD NAME="LINE5" SPACETRIMMING="FALSE"> 
<FORMATTER_FIELD SEQ="1" NAME="LetterHead_Row_5"/> 
</PRINTFIELD> 

<PRINTFIELD NAME="LINE6" SPACETRIMMING="FALSE" > 
<FORMATTER_FIELD SEQ="1" NAME=" LetterHead_Row_6"/> 
</PRINTFIELD> 

<PRINTFIELD NAME="LINE7" SPACETRIMMING="FALSE"> 
<FORMATTER_FIELD SEQ="1" NAME="LetterHead_Row_7"/> 
</PRINTFIELD> 

<PRINTFIELD NAME="SENDER" SPACETRIMM]NG="FALSE"> 
<STATIC_FIELD SEQ="1" VALUE="DIRON Wirtschaftsinformatik GMBH 
&CO.KG 

- Daimlerweg 39-41 - 48163 Miinster, Gennany'V> 
</PRINTFIELD> 

<PRINTFIELD NAME="SALUTATI01Sr' SPACETRIMMING="FALSE"> 

<FORMATTER_FIELD SEQ="1" NAME="SalutationLine"/> 

</PRINTFIELD> 

</PRINTFIELD_MAPPING> 

<PRINTFIELD_POSITIONS> 

<POSITION POSX="25'TOSY="250" FONT="HELVETICA" 
FONTSIZE="10" 

COLOR="BLACK" PAGEFROM="l"PAGETO="l" NAME="LINEl"/> 

<POSITION POSX="25"POSY='*246" FONT="HELVETICA" 

FONTSIZE="10" 

COLOR="BLACK" PAGEFROM="l "PAGETO="l " NAME="LINE2'V> 

<POSITION POSX="25"POSY="242" FONT="HELVETICA" 

FONTSIZE="10" 

COLOR="BLACK" PAGEFROM="l "PAGETO'T' NAME="LINE3'7> 

<POSITION POSX="25"POSY="238" F0NT='™LVETICA" 

FONTSIZE="10" 
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COLOR="BLACK" PAGEFROM=" 1 "PAGETO=" 1 " NAME="LINE4"/> 

<POSITION POSX="25"POSY="234" FONT="HELVETICA" 
FONTSIZE="10" 

COLOR="BLACK" PAGEFROM="l "PAGETO="l " NAME="LINE5"/> 

<POSITION POSX="25"POSY="230" FONT="HELVETICA" 
FONTSIZE="10" 

COLOR="BLACK" PAGEFROM="l "PAGETO="l " NAME="LINE6"/> 

<POSITION POSX="25"POSY="226" FONT="HELVETICA" 
FONTSIZE="10" 

COLOR=''BLACK" PAGEFROM="l"PAGETO="l" NAME="LINE7"/> 

<POSrnON POSX="25"POSY="189" FONT="HELVETICA" 

FONTSIZE="10" 

COLOR="BLACK" PAGEFROM="r' PAGETO="l" 
NAME="SALUTATION"/> 

<POSITION POSX="25'TOSY="260" FONT="HELVETICA" 
FONTSIZE="6" 

COLOR="BLACK" PAGEFROM="l" PAGETO="l" 

NAME="SENDER"/> 

</PRINTFIELD_POSITIONS> 

</PRINTING_INSTRUCTIONS> 

<yUSERJOB HANDLING INSTRUCTIONS> 



RecreateXML preferably uses an address formatter on the basis of which it generates 
print instructions that are understood by the PDF kernel. The print instructions for the 
25 above-mentioned file in the PrintJob file look, for example, like this: 
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<VariableData StartPage="l" Step="l " EndPage="l"> 

<ADDTEXT RECORD="LINEl" yPos="250" Coloi="BLACK". FontSize="10" 
xPos="25" 

Font="HELVETICA"/> 

<ADDTEXT RECORD="LINE2" yPos="246" eoloi="BLACK" FontSize="10" 
xPos="25" 

Font="HELVETICA"/> 

<ADDTEXT RECORD="LINE3" yPos="242" Color="BLACK" FontSize="10" 
xPos="25" 

Font="HELVETICA"/> 

<ADDTEXT RECORD="LINE4" yPos="238" Color="BLACK" FontSize="10" 
xPos="25" 

Font="HELVETICA"/> 

<ADDTEXT RECORD="LINE5" yPos="234" Color="BLACK" FontSize="10" 
xPos="25" 

Font="HELVETICA"A> 

<ADDTEXT RECORD="LINE6" yPos="230" Color="BLACK" FontSize="10" 
xPos="25" 

Font="HELVETICA"/> 

<ADDTEXT RECORD="LINE7" yPos="226" Color="BLACK" FontSize="10" 
xPos='*25" 
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Font="HELVETICA'V> 

<ADDTEXT RECORD="SALUTATION" yPos="189" Color="BLACK' 
FontSize="10" 

xPos ="25" Font="HELVETICA"/> 

<ADDTEXT RECORD="SENDER" yPos="260" Color="BLACK" FontSize="6" 
xPos="25" Font="HELVETICA"/> 
<;A^ariableData> 
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In the UserJob XML file, the variable data looks, for example, like this: 
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<USERJOB_VARIABLE_DATA> 

<RECORD SORT_ID="5" TYPE="1" SEQ="5"> 

<d07>City </d07> 

<d06>PostalCode/d06> 

<d05>System<d05> 

<d04>LastName</d04> 

<d03>FirstName</d03> 

<d02>Mr.</d02> 

<d01>Mr. FirstName LastName</d01> 

<d00>Company</d00> 

</RECORD> 



25 <yUSERJOB VARIABLE DATA> 



Using the allocation in the Print Instrudt file. Recreate XML generates the following 
on this basis: 



30 <THE_DATA> 

<RECORD SORT_ID="5" SEQ="5"> 

<LINE4>PostalCode City</LINE4> 

<LINE3>System</LINE3> 

<LINE2>Mr. FirstName LastName</LINE2> 
35 <LINEl>Company</LINEl> 
<SENDER>Sender</SENDER> 

<LINE7/> 

<S ALUTATION>Dear Mr. FirstName LastName,</S ALUTATION > 

<LINE6/> 
40 <LINE5/> 
</RECORD> 
</THE DATA> 
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In this manner, the personalization during the production yields the data that is 
available in a form in which the PDF kernel can use it directly. 
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The QueueManager administers the status for all UserJobs, PrintJobs and Plys. The 
QueueManager is notified of status changes by a data model of an interface. Here, for 
example, the following status can occur: 

5 

Status Display in the interface 

Intervention_Required Intervention required 
Not_Producible Production not possible 

Waiting Waiting 
Downloaded Downloaded 
Failed Production failed 

Ready_For_Download Downloadable 
Canceled Canceled 
Preprocessing In pre-production 

Preprocessed Pre-processed 
Printed Printed 
Delivered Delivered 

It has also proven to be advantageous for the QueueManager to set a Percentage 
attribute in case of status changes with the UserJobs and PrintJobs. This attribute 
indicates the completion of the UserJob in terms of a percentage. This value is trans- 
10 mitted for each UserJob during the synchronization with the server 20. The status of 
the UserJob and PrintJob in conjunction with the percentage of the completion are 
shown in the following table: 



UserJob Status Status of the associated Percentage of completion 

PrintJobs 

Intervention_Required - 10 

Not_Producible , - 0 

Waiting Waiting 10 

Downloaded - 5 

Failed 

Ready_For_Download - 0 

Canceled Last value before 

cancellation 
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Preprocessing 

Preprocessed 

Preprocessed 



Preprocessing 
Preprocessed 
Preprocessed / Printed 



10-95, depending on the 
number of completed 
PrintJobs 



10 



10 



Printed 



Printed 



95 



Delivered 



Delivered 



100 



It is especially advantageous if users of the print job generation element 15 according 
to the invention can use a user interface to oversee and control the production within a 
printing system 10. The interface can be implemented, for example, by using Java 
Swing. The data for the interface is administered, for example, by a DataModel class 
that queries the QueueManagei* in order to ascertain values. 

It is also advantageous for a user to be able to log in, log out and end the program via 
a menu in the SOAP server. These functions are preferably made available in a 
toolbar. During log-in, for example, a dialog box can be opened in which the user 
name and the password are to be entered. With this information, the system attempts 
to log into the SOAP server via an AuthenticateUser method from the ServerProxy. If 
the log-in is successful, then the user information is stored in the data model. This 
user information is employed for further communication with the server. In case of an 
error, it as advantageous for a dialog box with an error message to appear. 

It is advantageous to implement a "log-out" function that deletes user information 
from the data model so that no commimication is possible with the server without 
logging in once again. Another "log-out and end" function checks, for example, if 
production threads are still running. If there are still threads, another query is 
laimched asking whether the program is to be ended. The program is ended, for 
example, with System.exit(O). 

Via a ComboBox, for example, three different views of the User Jobs can be created. 
For all views, there are inner model classes in the main frame class (FrmApplication). 
The main frame initializes several ChangeListeners that set the possible actions in 
case of a change in the UserJob selection and in case of a UserJob status change. The 



possible actions are queried from the data model. The data model derives the possible 
actions from the status of the selected UserJobs that is queried by the QueueManager. 

Via the UserJob menu, UserJobs can be downloaded, converted into PrintJobs, 
5 canceled, set at not-producible, reset and produced with a wizard. All actions can be 
launched via a toolbar. The possible actions depend on the status of the selected 
UserJobs. 

The allocations between UserJob status and possible action are compiled in the 
10 foUoAving table: 

Status of the Possible actions 

selected UserJobs 

Downloadable Download, production wizard 



Downloaded 



Create new PrintJob (if all of the selected UserJobs are 
allowed to be combined into one PrintJob), cancel, 
production wizard 



Waiting 

Pre-produced 

Printed 



Delivered 



Intervention 
required 

Production failed 



UserJob not producible 



Canceled 



Reset 



The consequences of the UserJob actions are compiled in the following table: 



Action 



Consequence 



Downloading 



The selected UserJobs are downloaded from the 
PartnerServerProxy in their own thread by calling the 
ExportUserJob m ethod. The Q ueueManager i s n otified t hat 
the UserJobs have been downloaded 



Create 
PrintJob 



new One or more PrintJobs are generated on the basis of the 
selected UserJobs. This gives rise to new XML files in which 
the UserJob files are decoded and converted with the 
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Recreate XML class into a new XML format that can be read 
by the PDF kernel. Then the QueueManager is notified as to 
which User Jobs became which PrintJobs. 

UserJob not The type of error and a comment are requested. The Queue- 

producible Manager is notified. 

Production wizard The wizard is started, which downloads all of the selected 
UserJobs, generates a PrintJob in each case and then pro- 
duces it. 

Canceling The QueueManager is notified that the selected UserJobs are 

to be canceled. 

The use of a production wizard is especially advantageous. The production wizard 
groups all of the selected UserJobs according to products. If no UserJob was selected, 
then all UserJobs are used. For purposes of grouping, the wizard uses, for example, 
5 the PRINT^MODE, PRINTjCOLOR and PRINT__FORMAT attributes. The following 
table shows the wizard products and their attributes: 



Wizard product 
Colored, simplex 
Colored, duplex 
b/w, simplex 
b/w, duplex 
Funcard 



PRINT_MODE 

SIMPLEX 

DUPLEX 

SIMPLEX 

DUPLEX 



PRINT_COLOR 

4C 

4C 

b/w 

b/w 



PRINT_FORMAT 

DIN A4 

DIN A4 

DINA4 

DINA4 

DINA6 



The view of the PrintJobs can likewise be made selectable via a ComboBox. The 
views and the action handling are implemented as with the UserJobs, but with the 
difference that the values for PrintJobs are queried by the QueueManager. 



The possible actions depend on the status of the selected PrintJobs. The allocation 
between PrintJob status and possible action is compiled in the following table: 

Status of the Possible actions 
selected PrintJobs 

Waiting Producing, resolving, changing printer 

Pre-produced Print repetition, resolving, resetting 

Printed Print repetition, delivering, resolving 
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Intervention Produce, resolving, resetting 

required 

The following table shows the consequences of the PrintJob actions: 
Action Consequence 

Producing The PDF kernel is instructed to produce the PrintJob. The 

QueueManager is notified of the result of the production. 

Print repetition The PDF kernel is instructed to produce part of the PrintJob. 

The QueueManager is notified of the result of the produc- 
tion. 

Delivering The Q ueueManager i s n otified t hat t he P rintJob w as d eliv- 

ered. 

Changing printer The QueueManager is notified to set the printer. The only 
printers offered for selection are those on which the PrintJob 
is producible. The printers are queried by the Queue- 
Manager. 

Resetting The QueueManager is notified to reset the PrintJob. 

5 An advantageous embodiment of the invention is also that a user can perform 
synchronization via a server menu and reset the local cache. 

If a synchronization is performed, the print job generation element first uses the 
ServerProxy to send to the server every status and the degree of completion as a 

10 percentage value of the local UserJobs. If a UserJob has the status CANCELED, 
FAILED or DELIVERED^ the QueueManager is subsequently instructed to delete 
these local jobs. After the status transmission, the print job generation element queries 
all downloadable "exportable" UserJobs. If a downloadable UserJob is not yet present 
locally, then the QueueManager is instructed to create it. Then the attributes of this 

15 new UserJob are queried by the server and the QueueManager is notified. If an error 
occurs during the querying of the attributes, the QueueManager is instructed to set this 
UserJob at NOTJPRODUCIBLE. 

In the next step, the print job generation element queries the list of already 
20 downloaded UserJobs from the SOAP server. If UserJobs that were already 

downloaded are no longer present locally, the UserJobs are newly created via the 
QueueManager and downloaded. This can take place, for example, if the local files of 
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the QueueManager are deleted. If there are local UserJobs that are not in the list of 
downloaded UserJobs, then these UserJobs are deleted locally. 

When the local cache is reset, to start with, all of the PrintFobs are eliminated. Then 
5 all of the files that are managed by the QueueManager are deleted. After the restart of 
the QueueManager that now takes place, a synchronization is performed in which, 
however, the transmission of the status to the SOAP server does not occur. 

In an especially preferred embodiment of the invention, all of the errors that occur 
10 within the print job generation element are displayed to the user in a dialog box. 

Moreover, the errors and the date are preferably stored in a log file. The file is called, 
for example, error.log and it is located in a path that is indicated in the configuration 
imder errorpath. 

15 Preferably, all of the information used for the production is stored in a Job- 
Environment. Here, to start with, all of the UserJobs contained in the PrintJob are 
stored in data objects of a UserJobData class. These data objects offer access to all of 
the UserJob data that is of importance for the production. In order for the total number 
to become known, the number of addresses, pages and sheets for all of the UserJobs is 

20 added and stored. 

JobEnvironment analyzes how many letters are intended for each InfoPost criterion, 
namely, InfoLetter, InfoPost or Standard. A data object of a Letter class is generated 
on the basis of each address. For the fiuther production sequence, JobEnvironment 
25 . makes methods available in order to query certain information via the UserJob. 

The Letter class contains information for a letter. This includes, for example, 
personalization information, the number of letter pages, the InfoPost criterion, the 
UserJobK) and the position within the UserJob. The JobEnvironment manages a list 
30 with letter objects for all letters. 

Preferably, an object of the UserJobData class contains all data of a UserJob. This 
includes all UserJob attributes as well as information about postage, price and com- 
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pany. The JobEnvironment has a Hst of UserJobs with all of the UserJobData objects 
of the job. The UserJobData class offers methods to access the UserJob information. 

In order to manage the PDF page content, it is advantageous to use a PageContent 
S class. Objects of this class describe for a page which letters are located on the page in 
which position. It is possible for several letters to be located on one page after the 
impositioning has been carried out. 

Preferably, a DocumentContent hash table is used to manage the page content for each 
10 PDF file. In it, the file names and a list of the PageContent are stored for all of the 
PDF documents. These are preferably generated by a PDFLayer. The information 
serves for generating an OMR and SDL and for generating a PDF template with static 
content. 

15 It is also advantageous that a PDF template with the static contents for an existing 
PDF file with personalization data can be generated at any desired place. In this 
process, it is checked which template pages are needed. Jn VariableToTemplateMatch, 
it is recorded which personalized pages belong to a static page. The information might 
be needed for a later generation of a book ticket. The VariableToTemplateMatch is 

20 entered in VarToTemplateMatchArray for each loop pass. 

After the JobEnvironment has been set, the printable files are generated by the PDF 
kemel on the basis of the virtual printer that is in the configuration. For this purpose, 
in an especially preferred embodiment of the invention, the kemel has several levels. 

25 On the top level (JobHandler), the virtual printer is selected, the PrintFob is read in 
and the JobEnvironment is initialized. Then the JobHandler incrementally processes 
the PrepareDocumentStep entries of the virtual printer. On this level, the NewPDF, 
Loop, Workflow, Personalize, CreatetemplatePDF, PersonalizeOnTemplate, Repeat 
and OpenPDF entries are recognized and, as a function of the keyword, a method of 

30 the next level is called. On the next level (DocumentHandler), the instructions present 
within the above-mentioned entries are evaluated. The entries that are present in these 
entries are evaluated by another level (PDFDocument). PDFDocxmient uses 
PDFLayer to open and generate the docimients. 
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In an especially preferred embodiment of the invention, an extemal PDFLib library is 
incorporated in order to generate and read in the PDF files. This library allows a quick 
generation of PDF documents by means of function calls. Existing PDF pages can 
thus also be inserted into new PDF documents. Access to this library preferably takes 
5 place via a PDFAccessLayer. In this manner, the remaining code is independent of the 
library and, in case of a transfer to another Hbrary, only the layer has to be adapted. 

The layer is also responsible for setting DocumentsContent in the JobEnvironment. 
Every time a new PDF file is created, an empty PageContent is created and the 

10 JobEnvironment is informed of this with the file name. During the personalization, the 
PDFLayer is informed as to which letter page is being placed. The PDFLayer 
generates an appropriate PageContent and gives it to JobEnvironment. Every time an 
existing file is opened, the PDFLayer retrieves the page content (PageContent) fi-om 
the JobEnvironment. When a page of this device is copied into a new document, the 

15 . PDFLayer computes the position of the page on the new page and thus generates a 
PageContent. 

In order to convert the PDF files into PostScript, it has proven to be advantageous to 
use a DLL pdflps Java under C. This DLL can address, for example, the Adobe 
20 Acrobat and Acrobat Reader programs. The DLL opens the programs and instructs 
them to convert a PDF file into PostScript. The DLL is loaded by the 

. PdflPsNativelnterface class. The PdflPsConverter class uses Pdf2PsNativeInterface 
and makes a conversion method available. 



47 



List of reference numerals: 





10 








nrinter 




12 


Qftrtino' rn5if*liinp 

OVX llXlg XXXAWXUXlw 






ciivciupuig rndLiiiiic 




1 A 


pnni processing componeni 




1 s 


pi liii J \ju ^diwiaiiviii ddiiCiii 




1 vl 


XilOIr lliCOOCl^C? 


1 f\ 


1 7 


s6conci message 




1 S 
1 o 


Call CloSS 




9n 
zu 


server 




21 


web server 




22 


proxy server 


15 


30 


database 




40 


first interface 




50 


second interface 




60 


Internet 



